Methods apparatus for allocating resources in the presence of uncertainty

ABSTRACT

A method of allocating resources in the presence of uncertainty is presented. The method builds upon deterministic methods and initially creates and optimizes scenarios. The invention employs clustering, line-searching, statistical sampling, and unbiased approximation for optimization. Clustering is used to divide the allocation problem into simpler sub-problems, for which determining optimal allocations is simpler and faster. Optimal allocations for sub-problems are used to define spaces for line-searches; line-searches are used for optimizing allocations over ever larger sub-problems. Sampling is used to develop Guiding Beacon Scenarios that are used for generating and evaluating allocations. Optimization is made considering both constraints, and positive and negative ramifications of constraint violations. Applications for capacity planning, organizational resource allocation, and financial optimization are presented.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a continuation of provisional patentapplication No. 60/116,785 filed on Jan. 21, 1999.

BACKGROUND TECHNICAL FIELD

[0002] This invention relates to methods and systems for allocatingresources in an uncertain environment.

[0003] This application is a continuation of Provisional PatentApplication No. 60/116,785 submitted Jan. 21, 1999. By reference thefollowing documents, submitted to the Sunnyvale Center for Innovation,Invention and Ideas (SCI³) under the US Patent and Trademark Office'sDocument Disclosure Program, are hereby included: Title Number DateMethod of Allocating Resources in a Stochastic S00463 Jul. 9, 1997Environment Method of Allocating Resources in a Stochastic S00730 Mar.16, 1998 Environment - Further Considerations Method of AllocatingResources in a Stochastic S00743 Apr. 10, 1998 Environment - FurtherConsiderations II Method of Allocating Resources in a Stochastic S00764May. 11, 1998 Environment - Further Considerations III Method ofAllocating Resources in a Stochastic S00814 Jul. 24, 1998 Environment -Further Considerations IV Methods and Apparatus for Allocating S00901Dec. 14, 1998 Resources in an Uncertain Environment - PPA Draft IMethods and Apparatus for Allocating S00905 Dec. 18, 1998 Resources inan Uncertain Environment - PPA Draft II Methods and Apparatus forAllocating S00914 Jan. 6, 1999 Resources in an Uncertain Environment -PPA Draft III

[0004] Copending patent application Ser. No. 09/070,130, filed on Apr.29, 1998, is incorporated herein, which application discloses severalstandard methods for allocating resources.

BACKGROUND OF PRIOR ART

[0005] Almost all organizations and individuals are constantlyallocating material, financial, and human resources. Clearly, how bestto allocate such resources is of prime importance.

[0006] Innumerable methods have been developed to allocate resources,but they usually ignore uncertainty: uncertainty as to whether theresources will be available; uncertainty as to whether the resourceswill accomplish what is expected; uncertainty as to whether the intendedends prove worthwhile. Arguably, as the increasingly competitiveworld-market develops, as technological advancements continue, and ascivilization becomes ever more complex, uncertainty becomes increasinglythe most important consideration for all resource allocations.

[0007] Known objective methods for allocating resources in the face ofuncertainty can be classified as Detailed-calculation, stochasticprogramming, scenario analysis, and Financial-calculus. (The terms“Detailed-calculation”, “Financial-calculus”, “Simple-scenarioanalysis”, and “Convergent-scenario analysis” are being coined here tohelp categorize prior-art.) (These known objective methods forallocating resources are almost always implemented with the assistanceof a computer.)

[0008] In Detailed-calculation, probabilistic results of differentresource allocations are determined, and then an overall best allocationis selected. The first historic instance of Detailed-calculation, whichled to the development of probability theory, was the determination ofgambling-bet payoffs to identify the best bets. A modern example ofDetailed-calculation is U.S. Pat. No. 5,262,956, issued to DeLeeuw andassigned to Inovec, Inc., where yields for different timber cuts areprobabilistically calculated, and the cut with the best probabilisticvalue is selected. The problem with DeLeeuw's method, and this is afrequent problem with all Detailed-calculation, is its requirement toenumerate and evaluate a list of possible resource allocations.Frequently, because of the enormous number of possibilities, suchenumeration and valuation is practically impossible.

[0009] Sometimes to allocate resources using Detailed-calculation, acomputer simulation is used to evaluate:

z _(dc) =E(ƒ_(dc)(x _(dc)))  (1.0)

[0010] where vector x_(dc) is a resource allocation plan, the functionƒ_(dc) evaluates the allocation in the presence of random,probabilistic, and stochastic events or effects, and E is themathematical expectation operator. With such simulation capabilities,alternative resource allocations can be evaluated and, of thoseevaluated, the best identified. Though there are methods to optimize thefunction, such methods often require significant amounts of computertime and hence are frequently impractical. (See Michael C. Fu's article“Optimization via Simulation: A Review,” Annals of Operations ResearchVol. 53 (1994), p. 199-247 and Georg Ch. Pflug's book Optimization ofStochastic Models: The Interface between Simulation and Optimization,Kluwer Academic Publishers, Boston, 1996.) (Generally knownapproximation solution techniques for optimizing equation 1.0 includegenetic algorithms and response surface methods.)

[0011] A further problem with Detailed-calculation is the difficulty ofhandling multiple-stage allocations. In such situations, allocations aremade in stages and between stages, random variables are realized (becomemanifest or assume definitive values). A standard solution approach tosuch multiple-stage Detailed-calculation resource allocations is dynamicprogramming where, beginning with the last stage, Detailed-calculationis used to contingently optimize last-stage allocations; thesecontingent last-stage allocations are then used by Detailed-calculationto contingently optimize the next-to-the-last-stage allocations, and soforth. Because dynamic programming builds upon Detailed-calculation, theproblems of Detailed-calculation are exacerbated. Further, dynamicprogramming is frequently difficult to apply.

[0012] Stochastic programming is the specialty in operationsresearch/management science (OR/MS) that focuses on extendingdeterministic optimization techniques (e.g., linear programming,non-linear programming, etc.) to consider uncertainty. The generalsolution approach is to construct and solve an optimization model thatincorporates all the possibilities of what could happen. Unless theresulting optimization model is a linear programming model, the usualproblem with such an approach is that the resulting optimization problemis too big to be solved; and aside from size considerations, isfrequently unsolvable by known solution means. Creating a linearprogramming model, on the other hand, frequently requires acceptingserious distortions and simplifications. Usually, using more than twostages in a stochastic programming problem is impractical, because theabove-mentioned computational problems are seriously aggravated.Assumptions, simplifications, and multi-processor-computer techniquesused in special stochastic programming situations fail to serve as ageneral stochastic-programming solution method.

[0013] In Simple-scenario analysis, future possible scenarios arecreated. The allocations for each are optimized, and then, based uponscenario probabilities, a weighted-average allocation is determined.Sometimes the scenarios and allocations are analyzed and, as aconsequence, the weights adjusted. The fundamental problem with thismethod is that it does not consider how the resulting allocationperforms against the scenarios, nor does it make any genuine attempt todevelop an allocation that, overall, performs best against allindividual scenarios. Related to this fundamental problem is theassumption that optimality occurs at a point central to individualscenario optimizations; in other words, that it is necessarily desirableto hedge allocations. Such hedging could, for example, lead tosub-optimality when, and if, the PRPA uses Simple-scenario analysis forallocating resources: because of economies of scale, it could bepreferable to allocate large resource quantities to only a few uses,rather than allocate small quantities to many uses. Another practicalexample concerns allocating military warheads, where hedging can becounter-productive.

[0014] Also related to the fundamental problem of scenario analysis isits inability to accommodate utility functions in general, and vonNeumann-Morgenstern (VNM) utility functions in particular. Arguably,according to economic theory, utility functions should be used for allallocations when uncertainty is present. Loosely, a utility functionmaps outcomes to “happiness.” The VNM utility function, in particular,maps wealth (measured in monetary units) to utility, has a positivefirst derivative, and, usually, has a negative second derivative. Bymaximizing mathematically-expected VNM utility, rather than monetaryunits, preferences concerning risk are explicitly considered.

[0015] (A classic example of Simple-scenario analysis theory is RogerJ-B. Wets' thesis, “The Aggregation Principle in Scenario Analysis andStochastic Optimization,” in: Algorithms and Model Formulations inMathematical Programming, S. W. Wallace (ed.), Springer-Verlag, Berlin,1989, p. 91-113.)

[0016] Simple-scenario analysis has been extended to what might becalled Convergent-scenario analysis, which starts where Simple-scenarioanalysis ends. Using a weighted-average allocation, individual scenariosare re-optimized with their objective functions including penalties (orcosts) for deviating from the average allocation. Afterwards, a newweighted-average allocation is determined, the penalties made moresevere, and the process is repeated until the individual scenarios'optimizations converge to yield the same allocation. The deficiencies ofSimple-scenario analysis as previously described remain, though they aresomewhat mitigated by the mechanism that coordinates individual-scenariooptimizations. The mechanism, however, is contingent upon arbitraryparameter values, and hence the mechanism itself arbitrarily forcesconvergence. Further, such forced convergence is done without regard towhether the current allocation actually improves. Further still, theconvergent mechanism tends to overly weigh scenarios that are highlysensitive to small allocation changes, even though it could be desirableto ignore such scenarios. Incorporating penalties for deviating from theaverage allocation can be cumbersome, if not impossible, and can resultin significantly complicating and protracting the solution procedure.

[0017] The Progressive Hedging Algorithm is the most famous of theConvergent-scenario analysis techniques and is described in R. TRockafellar and Roger J.-B. Wets, “Scenarios and Policy Aggregation inOptimization Under Uncertainty” Mathematics of Operations Research Vol.16 (1991), No. 1, p. 119-147. Other Convergent-scenario analysistechniques are described in John M. Mulvey and Andrzej Ruszczynski, “ANew Scenario Decomposition Method for Large-Scale StochasticOptimization,” Operations Research 43 (1995), No. 3, p. 477-490, andsome of the other prior-art references.

[0018] U.S. Pat. No. 5,148,365 issued to Dembo is anotherscenario-analysis method. Here, as with Simple-scenario analysis, futurepossible scenarios are created and the allocations for each areoptimized. Afterwards, the scenario allocations and parameters, possiblytogether with other data and constraints, are combined into a singleoptimization problem, which is solved to obtain a final allocation.Though this method mitigates some of the problems with Simple-scenarioanalysis, the problems still remain. Most importantly, it does not fullyconsider how the resulting allocation performs against all individualscenarios. This, coupled with the disparity between objective functionsused for optimization and actual objectives, results in allocations thatare only fair, rather than nearly or truly optimal. Because this methodsometimes uses a mechanism similar to the convergent mechanism ofConvergent-scenario analysis, the previously discussed convergentmechanism problems can also occur here.

[0019] As a generalization, all types of stochastic programming (andscenario analysis is a form of stochastic programming) can have thefollowing serious deficiencies when allocating resources. First,penalties can introduce distortions. Second, the process of formingtractable models can introduce other distortions. Third, existingtechniques are frequently unable to handle discrete quantities. Fourth,constraints are not fully considered, with the result that constraintsare violated with unknown ramifications, and, conversely, otherconstraints are overly respected. Fifth, existing techniques usuallypresume a single local optimum, though multiple local optimums can beparticularly probable. Sixth, existing techniques can requiresignificant computer time to compute gradients and derivatives. Seventh,and perhaps most important, practitioners frequently do not usestochastic programming techniques, because shifting from deterministictechniques is too complex.

[0020] Theoretical finance, theoretical economics, financialengineering, and related disciplines share several methods forallocating and pricing resources in the presence of uncertainty.(Methods for valuing or pricing resources also allocate resources, sinceonce a value or price is determined, it can be used for resourceallocation internally within an organization and used to decide whetherto buy or sell the resource on the open market.) These methods tend touse mathematical equations and calculus for optimization. A frequentproblem, however, is that once complicating factors are introduced, thesolution techniques no longer work, and either computer-simulationDetailed-calculation or stochastic-programming methods, with theirassociated problems, are required. A further problem is that suchmethods, in order to be mathematically tractable, frequently ignore VNMutility functions and work with unrealistically, infinitesimally smallquantities and values.

[0021] In conclusion, though innumerable methods have been developed todetermine how to allocate resources, they frequently are unable to copewith uncertainty. Attempts to include uncertainty frequently result inmodels that are too big to be solved, unsolvable using known techniques,or inaccurate. As a consequence, resource allocations of bothorganizations and individuals are not as good as they could be. It istherefore a fundamental object of the present invention to obviate ormitigate the above-mentioned deficiencies.

SUMMARY OF THE INVENTION

[0022] Accordingly, besides the objects and advantages of the presentinvention described elsewhere herein, several objects and advantages ofthe invention are to optimally, or near optimally, allocate resources inthe presence of uncertainty. Specifically, by appropriately:

[0023] 1. considering how the resulting allocation performs againstpossible scenarios

[0024] 2. utilizing von Neumann-Morgenstern or other utility functions

[0025] 3. hedging and not hedging

[0026] 4. handling uncertain constraints

[0027] 5. handling discrete-quantity requirements

[0028] 6. considering multiple local optimums

[0029] 7. using and capitalizing on known methods for allocatingresources that ignore, or do not explicitly consider, uncertainty

[0030] 8. using multiple processors.

[0031] Additional objects and advantages will become apparent from aconsideration of the ensuing description and drawings.

[0032] The basis for achieving these objects and advantages, which willbe rigorously defined hereinafter, is accomplished by programming acomputer as disclosed herein, inputting the required data, executing thecomputer program, and then implementing the resulting allocation. Theprogramming steps are shown in the flowchart of FIG. 1.

[0033] Step 101 entails generating scenarios and optimizing scenarioallocations. In Step 103, the optimized allocations are grouped intoclusters. In Step 105, first-stage allocations are randomly assigned toscenario nodes and, by using an evaluation and exploration technique tobe described, Guiding Beacon Scenarios (GBSs) are generated. Step 107entails using the GBSs and identifying the allocations within eachcluster that perform best against the scenarios within the cluster. InStep 109, allocations that perform better against the scenarios withineach cluster are created, typically by considering two of the betterallocations, and then using line-search techniques. If there is morethan one cluster, then in Step 113 the clusters are merged into largerclusters and processing returns to Step 109. Once only a single clusterremains and Step 109 is complete, the best allocation thus far obtainedis taken as the final optimal allocation and is implemented in Step 115.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The invention will be more readily understood with reference tothe accompanying drawings, wherein:

[0035]FIG. 1 shows a high-level flowchart;

[0036]FIG. 2 demonstrates optimized-scenario-allocation and clusterusage;

[0037]FIGS. 3A, 3B, and 3C demonstrate the three line-search techniques;

[0038]FIG. 4A shows an elementary scenario-tree; FIGS. 4A and 4Bcombined show the scenario-tree used by the present invention;

[0039]FIG. 5 is a skeletal definition of the WNode class;

[0040]FIG. 6 is a skeletal definition of the WScenario class;

[0041]FIG. 7 is a skeletal definition of the XAlloc class;

[0042]FIGS. 8A and 8B are skeletal definitions of the WWMatrix andAAMatrix classes;

[0043]FIG. 9 is a skeletal definition of theEvaluateXAllocAgainstWScenario function;

[0044]FIG. 10 is a skeletal definition of the DeterministicOptimizerfunction;

[0045]FIG. 11 is a skeletal definition of the ValueAllocation function;

[0046]FIG. 12 is a skeletal definition of the ZCluster class; and

[0047]FIGS. 13A and 13B show special von Neumann-Morgenstern utilityfunctions.

DETAILED DESCRIPTION OF THE INVENTION “Theory of the Invention”

[0048] Philosophy

[0049] The following philosophical assumptions are made:

[0050] 1. All resource allocations should fundamentally attempt todirectly or indirectly optimize one of three things: monetary gain,monetary loss, or what economists term “utility.”

[0051] 2. There is no such thing as a constraint violation; forfundamentally any constraint can be violated, though with consequences.These consequences can be quantified and expressed in the terms of therange of the objective function, provided that the objective function iscast as a fundamental type.

[0052] 3. The more a constraint is violated, the larger the adverseimpact on the fundamental objective being optimized.

[0053] 4. The adverse effect of a constraint violation is always lessthan infinity.

[0054] 5. Both objective and subjective probabilities are useful asimperfect estimates of what could happen.

[0055] 6. Almost every decision is a resource allocation, because almostevery decision directly or indirectly leads to a resource allocation.

[0056] 7. Every resource allocation (and decision) would be easier andsimpler if there was no uncertainty.

[0057] As an example of the first four items, a business might have aresource allocation plan that optimizes profits (monetary gain), andamong other things fulfills the requirement (constraint) thatcontractual obligations be met. However, it may happen that fulfillingthe contractual obligations becomes impossible. At this point, thoughthe constraint is violated, it is irrelevant. What is relevant is howbest to handle the contractual obligations: re-negotiating, performingrestitution, fulfilling some of the obligations, etc. Whatever course ischosen, there follows an adverse impact on the business' profits. Themore numerous and onerous the contractual obligations, the larger theadverse impact. However, this adverse impact is always less thaninfinity. There are always degrees of catastrophe: it is better to beshort 10M resource units, rather than 20M; it is better to be insolventby $30M, rather than $50M; etc.

[0058] As an example of the fifth item, an objective probabilitymeasurement might be obtained by statistical analysis of responses to alarge survey, while a subjective value by a guess. Lacking better bases,both are usable and valuable. (Given a choice between the two, however,the objective estimate is usually preferable.)

[0059] A consequence of the fifth item is a diminishment of the usualdistinction between risk and uncertainty. In common-professional usage,risk suggests known probabilities, while uncertainty suggests unknownprobabilities. Philosophically, however, one always can determine asubjective probability estimate. Hence, here no distinction is madebetween risk and uncertainty; the two words are used interchangeably.

[0060] This philosophical section is presented here to facilitate adeeper and broader understanding of how the present invention can beused. However, neither understanding this section nor agreeing with itare required for implementing or using this invention. Hence, thissection should not be construed to bound or in any way limit the presentinvention.

[0061] “Mathematical Framework”

[0062] As is standard in stochastic programming, resources in thisinvention are allocated in one or more stages, and, between stages, whatwere previously uncertain values either become known, or the uncertaintyof their eventual values reduced. Allocations made in one stage affectwhat can be accomplished in subsequent stages. Mathematically, thegeneral stochastic resource allocation model addressed here is:$\begin{matrix}{{{maximize}\quad z} = {\sum\limits_{i = {{each}\quad {scenario}}}{p_{i} \cdot {f\left( {a_{i},{WS}_{i}} \right)}}}} & (2.0)\end{matrix}$

[0063] where,

[0064] WS_(i) is a matrix containing all the random-variablerealizations for scenario i

[0065] a₁ is a vector containing first-stage allocations

[0066] ƒ is a function that evaluates first-stage allocations a₁ againstscenario i

[0067] p_(i) is the probability of scenario i

[0068] Implicit within function ƒ is the generation of a₂, a₃, . . .allocations for the second, third, and so-forth stages. Also implicit isan evaluation of such allocations. (Obviously, the maximizingorientation used here could have just as easily have been reversed.)

[0069] The focus here is on determining the optimal vector a₁, sincethose allocations are most immediately relevant, are initiallyimplemented, and are implemented prior to any additional informationbecoming available.

[0070] Several strategies are used in tandem to cope with the inherentNP-hardness of stochastic programming: clustering, line-searching,statistical sampling, and unbiased approximation. Clustering is used todivide the allocation problem into simpler sub-problems, for whichdetermining optimal allocations is computationally simpler and faster.Optimal allocations for sub-problems are used to define spaces forline-searches; line-searches are used for optimizing allocations overever larger sub-problems. Sampling is used to develop schemes used togenerate and evaluate allocations, especially for generating, and inturn using, GBSs.

[0071]FIGS. 2, 3, and 4A demonstrate some basic concepts that weredeveloped as part of this invention: FIG. 2 shows howindividual-scenario optimizations can serve as good starting points forfinding an overall optimal allocation and how clustering can facilitateoptimization; FIG. 3 shows the operation of special line-searchingtechniques to find better allocations; and FIG. 4A shows how GBSs aregenerated and used to evaluate a₁ allocations.

[0072]FIG. 2 depicts a hypothetical example with four scenarios. The a₁allocations are shown collapsed into a single dimension on thehorizontal axis; the vertical axis shows function ƒ and z values. Curves201, 202, 203, and 204 show ƒ values as a function of a₁ for the first,second, third, and fourth scenarios respectively. The optimal a₁ valuesfor the four scenarios are points 211, 212, 213, and 214. Given the fouroptimal points, they are clustered: points 211 and 212 into a cluster221; points 213 and 214 into a cluster 231. (The clusters include thescenarios themselves.) The value of z across both the first and secondscenarios is shown by curve 231; stated differently, curve 231 shows theprobabilistically-weighted average value of curves 201 and 202. Thevalue of z across the third and fourth scenarios by is shown by curve241. For both clusters, the optimal individual-scenario allocations aregood starting points for finding the optimal cluster allocations.Line-search techniques, to be explained shortly, are used to locate apoint 232 as the optimal allocation for cluster 221. For cluster 231,however, the third scenario's optimal allocation (point 213) is the bestcluster allocation. Now, the iteration repeats: the two clusterallocations points 232 and 213 are clustered into a larger finalcluster. The value of z across the four scenarios is shown by curve 251,and as analogous to using optimized-scenario allocations, the optimalallocations for the individual clusters serve as starting points forfinding the overall optimal allocation, point 261.

[0073]FIGS. 3A, 3B, and 3C show the operation of the three line-searchtechniques, each of which approximates function z with parabolas. Thethree techniques build upon one another. As before, the a₁ allocationsare shown collapsed into a single dimension on the horizontal axis; thevertical axis shows function z values. Points 300 and 301 correspond totwo allocations and define the line in the allocation space that issearched. (An allocation is a point in the allocation space, and for themoment the words “allocation” and “point” are used synonymously whenthey apply to the allocation space represented by the horizontal axis.)These two allocations have z values as indicated by points 310 and 311respectively. A parameter h, which can range from negative to positiveinfinity, governs the linear blending of allocations 300 and 301. In thefirst technique, Simple Parabola Search (SPS), a point 302 is selected(See FIG. 3A); the associated value z, point 312, is determined; aparabola through points 310, 312, and 311 is determined (shown asparabola 391); and the optimum domain value of the parabola, point 303,is evaluated for possibly yielding a better z value.

[0074]FIG. 3B shows allocation 303 yielding a value indicated by a point313, which is inferior to point 310. In such a case, the secondtechnique, Inner Compression Search (ICS), builds upon the failed SPSattempt. ICS hypothesizes that the z function is roughly like curve 392(shown passing through points 310, 314, 313, and 311), with a localoptimum near point 310 and between points 310 and 313. Initially, ICStests the hypothesis by determining whether an allocation 304, nearallocation 300, yields a z value better than allocation 300. If so, thepoint 313 of the SPS and the points 310 and 314 are used to determine aparabola and the optimum domain value of the parabola, point 305, isevaluated for yielding a better z value. If a better z value is notobtained, then the process repeats: using points 310, 314, and thez-value point for allocation 305, another parabola is determined, and soforth.

[0075] If the hypothesis proves incorrect (i.e., allocation 304 yieldsan inferior z value indicated by a point 324 in FIG. 3C), then the thirdtechnique, Outer Compression Search (OCS), builds upon the failed ICSattempt. Because allocation 300 yields a higher z value than allocation304, OCS presumes that the z function increases as h decreases fromzero. Such is exemplified by curve 393, which passes through points 310,324, and 311. Initially, OCS experiments with increasingly negative hvalues until an inferior allocation is obtained; afterwards, it appliesICS.

[0076]FIG. 4A shows an elementary scenario tree, and the generation anduse of Guiding Beacon Scenarios (GBSs). GBSs are applicable when thereare more than two stages. At node 411, the first-stage allocations a₁are made; at nodes 421 and 422, second-stage allocations a₂ are made; atnodes 431, 432, 433, and 434, third-stage allocations a₃ are made; andat nodes 441, 442, 443, 444, 445, 446, 447, and 448, fourth-stageallocations a₄ are made. Here, end-node identifiers are also used todesignate scenarios; it is uncertain whether scenarios 441, 442, 443,444, 445, 446, 447, or 448, will occur. (Vectors w₁, w₂, w₃ assumedifferent realizations of random variables for the eight scenarios.) Toevaluate a first stage a₁ allocation against, for example scenario 441,the first step is to determine the second stage allocations a₂. This isdone by assuming both that a₁ is fixed, and that the GBS of node421—either 441, 442, 443, or 444—will occur with certainty. Given thosetwo assumptions, the allocations of a₂, a₃, and a₄ are re-optimized. Thesecond step follows the first: Assuming that a₁ and a₂ are fixed, andthat the GBS of node 431—either 441 or 442—will occur with certainty, a₃and a₄ are re-optimized. The final step is to re-optimize a₄, holdinga₁, a₂, and a₃ fixed, and assuming scenario 441 occurs with certainty.The value of this final re-optimization is the value of the a₁allocation against scenario 441.

[0077] To generate GBSs, initially optimized a₁ allocations are randomlyassigned to the second and third stage nodes. Then, starting with athird stage node, for example node 431, for each assigned a₁ allocation,and for each subsequent node (441 and 442), what are here termed SpanOptimizations are performed: a₂, a₃, and a₄ are re-optimized, holding a₁fixed, and assuming the subsequent-node scenario occurs with certainty.Afterwards, for each Span Optimization, a₄ is re-optimized holding a₁,a₂, and a₃ fixed, and assuming the other subsequent node(s) occur withcertainty. Finally, the Span Optimization that performs best overall isidentified, and its scenario is selected as the GBS. (For example, todetermine the GBS for node 431, a₂, a₃, and a₄ are re-optimized holdinga₁ fixed, and assuming scenario 441 occurs with certainty (SpanOptimization); afterwards, a₄ is re-optimized holding a₁, a₂, and a₃fixed, and assuming scenario 442 occurs with certainty. If the SpanOptimization using scenario 441 performs better against scenarios 441and 442 than the Span Optimization using scenario 442, then the GBS fornode 431 is scenario 441.) The same is subsequently applied to the otherthird stage nodes. The GBSs for the second stage nodes are generatedsimilarly, though the third-stage GBSs are assumed to occur withcertainty.

[0078]FIGS. 2, 3A, 3B, 3C, and 4A, and this mathematical approachsection are here to facilitate understanding, and should not beconstrued to define or bound the present invention.

[0079] “Embodiments”

[0080] The basic embodiment of the present invention will be discussedfirst. Afterwards, the preferred embodiment, with its extensions of thebasic embodiment, will be presented.

[0081] Here, an Object Oriented Programming (OOP) orientation is used.Pseudo-code syntax is loosely based on C++, includes expository text,and covers only the particulars of this invention. Well-known standardsupporting functionality is not discussed or shown. Class names beginwith a special capital letter that helps distinguish a class from theconcept represented by the class. Variable names for class instancesbegin with a lower case letter and always include the class name.Data-types are usually implicit. Variables with suffix “Cntn” areinstances of a general pointer-container class, whose elements can befetched in a loop mechanism or referenced using an “[ ]” operator. Thesequence in which objects are fetched from instances of the generalpointer-container class is assumed to be constant; in order words,assuming the instance contains the same pointers, then every loopmechanism will always fetch the pointers in the same sequence, andsimilarly, the “[ ]” operator, with the same argument, will also fetchthe same pointer. Variable voa (value of allocation), which is used inboth classes and functions, contains the value of an optimizedallocation or an aggregation of such values. Vectors and arrays start atelement 0, which is frequently not used, so that element 1 correspondsto stage 1. Indentation is used to indicate a body of code or a linecontinuation. All variables (including matrixes and vectors) are passedto functions by reference. From now on, the term “optimize” (andcognates) may mean the application of formal mathematical techniquesthat yield global or local optimizations, but it also includes theapplication of any type of heuristic or rule-based decision-makingprocedure that would be expected to make or improve an allocation.

[0082]FIGS. 4A and 4B joined together show the general scenario treeused here. There are nStage allocations stages, a₁ through a_(nStage),and a_(nStage) is equal to, or greater than, two. Allocations may or maynot be needed for the last stage; however, to facilitate exposition,last stage allocations are presumed required and are always addressed.Though the figure shows two nodes following most nodes, any number ofnodes can follow all-but-the-last-stage nodes. Each last-stage node hasa pointer to a wScenario object, which contains scenario particulars.The w vectors contain different realizations of the random variables.

[0083]FIG. 5 shows a skeletal definition of the WNode class. The firstelement, pGBS, is a pointer to a wScenario object that serves as theGBS. This element is applicable for the second through the last-stagenodes. For last-stage nodes, pWScenario is applicable, and points to awScenario object, which defines a scenario. For the second through thenext-to-the-last-stage nodes, xAllocRndCntn contains xAlloc objects,which in turn contain a₁ vectors, used for generating GBSs. Data membernodeProbability is the probability of reaching the node, given that theimmediately preceding node has been reached. This class has a voamember. For all but the last-stage nodes, nextWNodeCntn containssubsequent nodes.

[0084] The skeletal definition of the WScenario class is shown in FIG.6. The first element, wwMatrix, is a WWMatrix object, which is definedbelow and contains w vectors. The second element, pWNode, is a vector ofpointers pointing to the wNodes that the scenario passes through. Theprobability of the scenario's occurrence is stored in nativeProbability.The function NativeOptimizer optimizes a₁, a₂, . . . , a_(nStage)allocations, assuming the scenario defined in wwMatrix occurs withcertainty. The resulting a₁ vector is stored in nativeXAlloc.

[0085] Class XAlloc is a wrapper for a₁ vectors and is shown in FIG. 7.Variable feasible is a Boolean indicating whether vector a₁ is feasible;member variable h, which is not always used, is the value that was usedto combine two a₁ vectors to yield the instance's a₁ vector. Membervariable voa is the standard voa variable. This class also has anassignment operator to copy a₁ vectors and h scalars between instancesand a comparison operator to compare the a₁ vectors of differentinstances. Comparisons between a, elements are done with a tolerance.

[0086]FIGS. 8A and 8B show class definitions of WWMatrix and AAMatrix,which respectively hold, as column-matrixes, vectors w and acorresponding to a complete scenario. The 0th column of both matrixes isnot used so that columns correspond to stages: e.g., vector w₃ is storedin column ww[ ][3]; vector a₄ is stored in column aa[ ][4]. All elementsof vectors w and a, and in turn arrays ww and aa, hold any data orfunction type required to define scenarios and specify allocations. Allvector and matrix elements are not necessarily used, and no relationshipor commonality necessarily exists between the elements in the same rowof ww (or aa). Both classes have h and voa members, as previouslydescribed.

[0087]FIG. 9 outlines the EvaluateXAllocAgainstWScenario function, whichis the pseudo-code implementation of the previously mentioned function ƒin equation 2.0. This function evaluates the a₁ vector contained in thefirst argument against the scenario contained in the second argument.Initially, an aaMatrix object is created and column aaMatrix.aa[ ][1] isloaded with the first-stage allocation vector (xAlloc.a1). Afterwards,stages two to nStage are iteratively re-optimized. During eachiteration, the DeterministicOptimizer function is called with threearguments: iFlexStage is the starting stage for which allocations can bere-optimized; aaMatrix contains fixed allocations made prior to stageiFlexStage; and wwMatrix is the GBS for the iFlexStage stage ofwScenario. The function finishes by passing voa to the first argument.

[0088]FIG. 10 outlines the DeterministicOptimizer function, which takesthe three arguments just described. Assuming that the scenario definedin wwMatrix occurs with certainty and holding the allocations inaaMatrix prior to stage iFlexStage fixed, this routine applies standardstate-of-the-art techniques to optimize allocations for stagesiFlexStage through nStage. The first step is to evaluate and respond towhat transpired up until the start of the iFlexStage. This could entailallocating resources to handle already incurred obligations, and couldentail determining resource quantities that are available as of theiFlexStage stage. The second step is to look forward and optimizeallocations for stages iFlexStage through nStage. This distinctionbetween a first and second step is really artificial, since what issought is a re-optimization of resource allocations: Given the portrayedsituation, determine the optimal resource allocations for stagesiFlexStage through nStage. This optimization process might entailapplications of “if . . . then . . . ” logic, “rules-of-thumb,”heuristics, expert-system-like computer code, OR/MS optimizationtechniques, or any other data-process or optimization technique thathelps to optimize resource allocations. Further, the flow through theroutine might be contingent upon fixed-earlier-stage allocation(s)(aaMatrix), stage (iFlexStage), and/or GBS (wwMatrix); for any givenfunction execution, multiple and on-the-fly creations/customizations ofoptimization models might occur and, between uses of such models, datamanipulated. Here the word “optimization” and conjugates are usedloosely, since true global optimization is not necessary. What isnecessary is to develop an allocation for stages iFlexStage and beyond.A simple reasonable allocation, assuming the same result for the sameiFlexStage, aaMatrix, and wwMatrix combination, would suffice.Obviously, though, the better the optimization, the better the finalallocation. This function finishes by setting columns iFlexStage,iFlexStage+1, . . . , nStage of aaMatrix.aa equal to the optimizedallocations for stages iFlexStage, iFlexStage+1, . . . , nStage,respectively; and calling the ValueAllocation function to set the voavalue.

[0089] A major advantage of the present invention is that stochasticresource-allocation optimization can be done using a deterministicperspective in the DeterministicOptimizer function. Deterministicresource-allocation optimization is better understood, more advanced,and simpler than prior-art stochastic optimization. (ThoughDeterministicOptimizer function allows a deterministic perspective, sucha perspective is not required. Hence, when a human expert definesDeterministicOptimizer functionality, it is acceptable to implicitlyconsider uncertainty.)

[0090] The ValueAllocation function, shown in FIG. 11, jointly assessesa scenario and an allocation to determine a voa value. This valuerepresents the desirability to have the scenario-allocation pair occur,as opposed to having any other scenario-allocation pair occur. Thiscould entail, for example, setting voa equal to:

[0091] the objective function value realized by theDeterministicOptimizer or the NativeOptimizer functions

[0092] the cash balance at the end of the last stage

[0093] the present-value of the stages' cash-flow stream

[0094] a VNM utility value based upon the monetary value at the end ofthe last stage

[0095] an aggregation of VNM utility values based upon monetary valuesat different stages

[0096] a non-VNM utility functional value

[0097] Philosophically, the ValueAllocation function interprets andconverts the results of an optimization into units of one of the threefundamental objectives: monetary gain, monetary loss, or utility.

[0098] An advantage of the present invention is to permit theNativeOptimizer and the DeterministicOptimizer functions to useundefined or expedient-optimization objectives and have theValueAllocation function interpret and value the results, so thatoptimal allocations can be made in the presence of uncertainty.

[0099]FIG. 12 shows the skeletal definition of the ZCluster class. ThewScenarioCntn member contains wScenario objects belonging to thecluster. The first-stage allocations that perform best for the clusterare stored as xAlloc objects in xAllocBestCntn; the optimal first-stageallocation is also stored in xAllocOpt. The function XAllocEvaluatorevaluates first-stage allocation xAlloc across all scenarios within thecluster; the ConsiderAppendBestXAlloc function manages xAllocBestCntn.The Improver function finds better first-stage allocations by using theSimpleParabolaSearch, InnerCompressSearch, and OuterCompressSearchfunctions. These functions in turn use several XAlloc instances: xAlloc0and xAlloc1 are two good allocations used to find better allocations(and correspond to points 300 and 301 of FIG. 3A.); xAlloch is theresult of merging allocations xAlloc0 and xAlloc1; xAlloc0off is anoffset from xAlloc0 (and corresponds to point 304 of FIG. 3B); xAllocBndis used by InnerCompressSearch to close-in on a better allocation (andcorresponds to point 303 of FIG. 3B). Function GenxAlloch generates andevaluates xAlloch; variable wasImproved is a Boolean indicating whetherGenxAlloch yielded an overall better first-stage allocation. VariablexAllocHurdle is an allocation to be surpassed in an iteration ofImprover.

[0100] In Step 101, prior-art techniques are used to create scenariosand build a scenario tree, like that shown in combined FIGS. 4A and 4B,with wNode and wScenario objects. Scenario creation could be done by ahuman expert and/or by computer generation. Each scenario consists of arealization of exogenously-determined random variables. Scenarios mayinclude exogenous changes to resource levels that occur during one ormore of the stages. So, for example, a particular stage of each scenariomay have a variable representing the realization of a contingentfinancial liability; such a realization changes available cash, and theoptimizations/allocations are done assuming that available cash isappropriately reduced at the particular stage. (This does not rule outallowing insurance to be purchased in an earlier stage in order tooffset the contingent-liability realization.)

[0101] If it is possible to obtain or calculate estimates of scenarioprobabilities, then such estimated values should be indicated innativeProbability; if such estimates are not available, then allwScenario.nativeProbability values should be set to the inverse of thenumber of generated scenarios. After scenario creation, for eachwScenario object, the NativeOptimizer function is called to optimizeallocations for all stages within the scenario, assuming the scenariooccurs with certainty. NativeOptimizer in turn calls ValueAllocation toproperly determine voa. The resulting first-stage allocation is storedin nativeXAlloc, along with voa. If, in a given wScenario instance,there are multiple-globally-optimal first-stage allocations and they caneasily be identified, then one should be randomly selected for storagein nativeXAlloc. (Programmatically, NativeOptimizer might call theDeterministicOptimizer function with a 1 value for iFlexStage, an emptyaaMatrix, and the wScenario's wwMatrix.)

[0102] In Step 103, using the first-stage allocations contained innativeXAlloc.a1 as coordinates, the wScenario objects are clustered(many prior-art clustering techniques are available). Clustering doesnot need to be academically pure: for instance, ordinal numeric valuescould be treated as if they were interval numeric values, some“difficult” fields ignored, etc. The value of nativeXAlloc.voa couldalso be used, though it is not necessary. A cluster may have one or morewScenario objects. Prior to clustering, vectors nativeXAlloc.a1 shouldtemporally be normalized, so that some dimensions do not dominate theclustering process. For each identified cluster, instances of theZCluster class are created and wScenarioCntn member is loaded with thewScenario objects belonging to the identified cluster.

[0103] In Step 105, where Guiding Beacon Scenarios are generated, thefirst operation is to set the pGBS member of each the last-stage wNodeequal to the instance's member pWScenario. Next, all xAllocRndCntncontainers in all wNode objects are emptied. Afterwards, thenativeXAlloc objects of all wScenario objects are weighted bynativeProbability, are randomly selected, and are loaded into thexAllocRndCntn containers of the second through nStage-1 nodes. (Whenthere are only two stages, this Step 105 should be skipped.) Each suchxAllocRndCntn container needs to be loaded with at least onenativeXAlloc; the same nativeXAlloc may be loaded into multiplexAllocRndCntn containers. The GBSs for stages two through nStage-1 aregenerated by: AAMatrix aaMatrix; for(iStage = nStage −1; 2 <= iStage;iStage--)   for(iNode = each iStage stage node)   {   for(jNode = eachiStage + 1 stage node that follows iNode)     {     jNode.voa = 0;    for(kxAlloc = each xAlloc contained in xAllocRndCntn of     iNode)      {       copy vector a1 of kxAlloc to column-vector      aaMatrix.aa[][1];       DeterministicOptimizer(2, aaMatrix,      jNode.pGBS->wwMatrix);       jNode.voa = jNode.voa +aaMatrix.voa *       jNode.nodeProbability;       for(1Node = eachiStage + 1 stage node that follows iNode       and is         not equaljNode)           {           DeterministicOptimizer(iStage + 1,aaMatrix,            1Node.pGBS->wwMatrix);           jNode.voa =jNode.voa + aaMatrix.voa *            1Node.nodeProbability;           }      }   Set jNode = the iStage + 1 node that follows iNode and has  the highest voa;   iNode.pGBS = jNode.pGBS;   }

[0104] In Step 107, identifying the best allocations within the clustersentails: for each cluster   {   clear xAllocBestCntn;   xAllocOpt.voa =negative infinity;   for(iwScenario = each wScenario contained inwScenarioCntn)     XAllocEvaluator(iwScenario.nativeXAlloc, TRUE);   }

[0105] The called XAllocEvaluator function member of the ZCluster classis: ZCluster::XAllocEvaluator(xAlloc, OKadd)   {   VOA voa;   voa = 0;  for(iwScenario = each wScenario in wScenarioCntn)     {    EvaluateXAllocAgainstWScenario(xAlloc, iwScenario);     voa = voa +xAlloc.voa * iwScenario.nativeProbability;     }   xAlloc.voa = voa;  //after the above first loop, the following is performed:  if(xAllocOpt.voa < xAlloc.voa)     {     xAllocOpt = xAlloc;     }  if(xAllocHurdle.voa < xAlloc.voa)     {     xAllocHurdle = xAlloc;    wasImproved = TRUE;     }   if(OKadd)     {     XAlloc xAllocDel;    xAllocDel = xAlloc in xAllocBestCntn with lowest voa;    ConsiderAppendBestXAlloc(xAlloc, xAllocDel);     }   }ZCluster::ConsiderAppendBestXAlloc(xAllocAdd, xAllocDel)   {  if(xAllocAdd not in xAllocBestCntn)^(#)     {    if(xAllocBestCntn.IsFull( ))       {       if(xAllocDel.voa <xAllocAdd.voa)         {         remove xAllocDel from xAllocBestCntn;        add xAllocAdd to xAllocBestCntn;         }       }     else      add xAllocAdd to xAllocBestCntn;     }   else     {     find isuch that xAllocBestCntn[i] equals xAllocAdd and    xAllocBestCntn[i].voa is       minimized;    if(xAllocBestCntn[i].voa < xAllocAdd.voa)       xAllocBestCntn[i] =xAllocAdd;     }   }

[0106] # Using the comparison operator of the XAlloc class. The purposehere is to prevent xAllocBestCntn from being flooded with roughlyequivalent allocations.

[0107] Step 109 entails:

[0108] for each cluster

[0109] Improver( );

[0110] Cluster member function Improver entails: Improver( )   {  Perform the following, one or more times:     xAllocOpt.h = 0;    xAlloc0 = xAllocOpt;     Randomly select an xAlloc object fromxAllocBestCntn that has     not previously been       paired with(within current zCluster instance), and is       different from, thecurrent       xAllocOpt.     xAlloc1 = randomly selected xAlloc;    xAlloc1.h = 1;     xAllocHurdle = xAlloc1;     xAllocBnd = xAlloc1;    wasImproved = false;     SimpleParabolaSearch( );    if(!wasImproved)       InnerCompressSearch( );     if(!wasImproved)      OuterCompressSearch( );     if(wasImproved)      ConsiderAppendBestXAlloc(xAllocHurdle, xAlloc1);   }

[0111] The SimpleParabolaSearch function uses the parameter h, which canrange from negative to positive infinity. The preferred values arebetween 0 and 1, with a slight extra preference for the value to be lessthan 0.5, presuming xAlloc0.voa is better than xAlloc1.voa. Pseudo-codefollows: ZCluster::SimpleParabolaSearch( )   {   Do the following, oneor more times, each time with a different h   value:     {    GenxAlloch(h);     if( 0 < xAlloch.h < xAllocBnd.h )       xAllocBnd= xAlloch;     if(wasImproved)       {       Determine the parabolapassing through the       following three points(where the first        coordinate is the domain and the second         coordinate therange):         •(0, xAlloc0.voa),         •(h, xAlloch.voa),        •(1, xAlloc1.voa);       if(such a parabola exists and has amaximal value)         {         Set h2 equal to the domain value thatyields         the maximal value;         GenxAlloch(h2);         }      if( 0 < xAlloch.h < xAllocBnd.h )         xAllocBnd = xAlloch;      exit function;       }     }   }

[0112] The GenxAlloch function, with its h argument, follows:ZCluster::GenxAlloch(h)   {   for(i=0;i<number of elements in vector a1;i++)     if(a1[i] is interval or ratio numeric)       {      xAlloch.a1[i] = (1−h) * xAlloc0.a1[i] + (h) * xAlloc1.a1[i];      if(xAlloch.a1[i] should be discrete)         round xAlloch.a1[i]to be discrete;       if(xAlloch.a1[i] is necessarily out of bounds)        bring xAlloch.a1[i] within bounds;       }     else if(a1[i] isan ordinal numeric)       {       set xAlloch.a1[i] equal the ordinalvalue that is closest       to/most associated with:         (1−h) *xAlloc0.a1[i] + (h) * xAlloc1.a1[i];       }     else       {      if(h<=0.5)         xAlloch.a1[i] = xAlloc0.a1[i];       else        xAlloch.a1[i] = xAlloc1.a1[i];       }   //after the above firstloop, the following is performed:   xAlloch.h = h;   if(xAlloch.a1 isfeasible)     {     XAllocEvaluator(xAlloch, FALSE);    xAlloch.feasible = TRUE;     }   else     {     dis =minimum(abs(h), abs(h−1));     xAlloch.voa = (lowest voa contained inxAllocBestCntn's     xAlloc     objects) − (positive       constant) *dis * dis;     xAlloch.feasible = FALSE;     } }

[0113] Two approaches to “infeasible” first-stage allocations can beused. The first is simply to work with it; namely, haveDeterministicOptimizer determine the result of attempting to implementsuch first-stage allocations. The second approach, which is shown aboveand is preferable, is to generate a penalty for non-feasibility. Thepenalty mechanism results in the allocation never being accepted, but isin keeping with the search techniques and allows processing to continuesmoothly. (Note that infeasibility discussed in this paragraph is forfirst-stage allocations. Such allocations might result in“infeasibility” in subsequent stages, but as discussed previously,constraints can always be violated, though with consequences. Part ofthe purpose of the DeterministicOptimizer function is to evaluate, andwork with, such consequences.)

[0114] The InnerCompressSearch function uses a parameter h3. Thisparameter needs to be between zero and xAllocBnd.h, such that theGenxAlloch function generates an xAlloch that is near, but not equal to,xAlloc0. ZCluster::InnerCompressSearch( )   {   GenxAlloch(h3);  xAlloc0off = xAlloch;   if(xAlloc0.voa < xAlloc0off.voa)     {     doone or more times:       {       Determine the parabola passing throughthe       following three points:         •(0, xAlloc0.voa),        •(xAlloc0off.h, xAlloc0off.voa),         •(xAllocBnd.h,xAllocBnd.voa);       if(such a parabola exists and has a maximal value)        {         Set h4 equal to the domain value of the parabola that        yields the maximal range           value;         if(h4 between0 and xAllocBnd.h)           {           GenxAlloch(h4);          xAllocBnd = xAlloch;           }         else           exitfunction;         }       else         {         exit function;        }       }     }   }

[0115] The OuterCompressSearch function uses a parameter hDec that canbe any positive value. ZCluster::OuterCompressSearch( )   {   XAlloctrailxAllocl, trailxAllocm, trailxAllocr;   XAlloc org0, org1;  trailxAllocm = xAlloc0;   trailxAllocr = xAlloc1;   org0 = xAlloc0;  org1 = xAlloc1;   h5 = 0;   do one or more times:     {     h5 = h5 −hDec;     GenxAlloch(h5);     if(trailxAllocm.voa < xAlloch.voa)       {      trailxAllocr = trailxAllocm;       trailxAllocm = xAlloch;       }    else       {       trailxAlloc1 = xAlloch;      if(trailxAlloc1.feasible)         {         Determine the parabolapassing through the following         three points:          •(trailxAlloc1.h, trailxAlloc1.voa),          •(trailxAllocm.h, trailxAllocm.voa),          •(trailxAllocr.h, trailxAllocr.voa);         if(such aparabola exists and has a maximal value)           {           Set h5equal to the domain value of the parabola           that yields themaximal range             value;           GenxAlloch(h5);          if(trailxAllocm.h < xAllocOpt.h)             trailxAllocl =trailxAllocm;           }         }       xAlloc0 = xAllocOpt;      xAlloc1 = trailxAllocl;       xAllocBnd = xAlloc1;      xAllocBnd.h = 1;       lnnerCompressSearch( );      if(InnerCompressSearch improved xAllocHurdle)         {        xAllocHurdle.h = xAlloc0.h −           (xAlloc0.h − xAlloc1.h) *xAllocHurdle.h;         }       xAlloc0 = org0;       xAlloc1 = org1;      exit function;       }     }   }

[0116] If there is more than one cluster remaining, Step 113 isperformed after Step 109. Similar to Step 103, using the zCluster'svector xAllocOpt.a1 as coordinates, the clusters are clustered into newlarger clusters. For each identified new larger cluster: create zClusterinstance newZCluster; for(each old cluster being merged intonewZCluster)   add each wScenario in oldZCluster.wScenarioCntn to  newZCluster.wScenarioCntn; for(each old cluster being merged intonewZCluster)   {   for(xAllocPrev = each xAlloc inoldZCluster.xAllocBestCntn)     newZCluster.XAllocEvaluator(xAllocPrev,TRUE);   destroy oldZCluster;   }

[0117] After the clusters have been merged, processing resumes at Step109.

[0118] If there is only one cluster remaining, Step 115 is performedafter Step 109. It entails implementing the first-stage resourceallocations indicated in vector xAllocOpt.a1 of the last remainingzCluster. (After implementation and the subsequent actual realization ofw₁, the complete process described here is repeated, with the secondstage having become the first stage, the third stage having become thesecond, and so forth.)

[0119] “Miscellaneous Considerations”

[0120] Functions ZCluster::XAllocEvaluator (of each ZCluster instance),EvaluateXAllocAgainstWScenario, and DeterministicOptimizer should avoidrepeating lengthy calculations when given the same arguments. This canbe accomplished by the following: at the end of each function call, thearguments and results are stored; at the start of each function call, ifthe same arguments are being used again, then the associated previousresults are retrieved.

[0121] Further along these lines, if the NativeOptimizer and/orDeterministicOptimizer functions generate difficult-to-reproduceintermediate results that could be used for re-optimization, then suchresults should be saved for reuse.

EXAMPLE RESOURCE ALLOCATIONS

[0122] The following examples are presented here to demonstrate some ofthe uses, usefulness, and scope of the present invention. These examplesare meant to be illustrative, and should not be construed to define orbound the present invention.

Example 1 Designing a New Manufacturing Facility with Uncertain FutureDemand

[0123] Capacity requirements for a new manufacturing facility areneeded, but it is uncertain what they should be, because future productdemand is uncertain and seasonal.

[0124] A five-stage resource-allocation optimization is appropriatehere. The first stage concerns determining capacity levels orinvestments, and the second through the fifth stages concern allocatingthat capacity to meet seasonal demand. Scenarios are generated and ascenario-tree is constructed. The NativeOptimizer function member ofeach wScenario object determines optimal capacity, assuming thescenario's product-demand level (specified in wwMatrix) occurs withcertainty. NativeOptimizer may entail use of expert-knowledge, mayentail use of OR/MS optimization techniques, or may determine capacityin a crude and lax manner. NativeOptimizer calls ValueAllocation tocompute ROI (return on investment) based upon first-stage capacityinvestments and the return during the four seasons.

[0125] Based upon first-stage capacity levels, the wScenarios areclustered into zCluster objects. WNode.xAllocRndCntn objects are loadedwith wScenario.nativeXAlloc objects, and the GBSs are generated. Bestfirst-stage capacity levels are identified and improved upon.

[0126] The DeterministicOptimizer function optimizes allocations formeeting seasonal demand, which correspond to stages two through five.The capacity allocations for stages iFlexStage through stage 5 arere-optimized, holding both first-stage capacity levels and allocationsfor stages two through iFlexStage-1 fixed. The function concludes bycalling ValueAllocation to determine the ROI based upon first-stagecapacity levels and the return during the four seasons. (In this case,the DeterministicOptimizer function is very different from theNativeOptimizer function, because the latter addresses optimizingcapacity levels, given fixed demand—while the former addressesoptimizing fixed-capacity allocations to best meet demand.)

[0127] Afterwards, the ZCluster::Improver function is executed for eachinstance and the zClusters are merged. The process repeats until only asingle zCluster remains. This zCluster's xAllocOpt contains the optimalcapacity levels for the new manufacturing facility.

Example 2 Cash Management with Uncertain Receipts and Uncertain Payouts

[0128] Corporate treasurers typically manage cash in order to meet cashrequirements and to maximize return. Both future requirements and futurereturns are frequently uncertain, and this invention can help optimizein the presence of such uncertainty.

[0129] The first step is to generate scenarios. Each stage of eachscenario (i.e., each w vector) has the following:

[0130] A) for each existing and possible-future investment:

[0131] cash requirements

[0132] cash receipts

[0133] acquisition price

[0134] divestiture price

[0135] B) contingent realizations of:

[0136] extra cash requirements

[0137] extra cash receipts

[0138] C) status data concerning:

[0139] interest rates

[0140] stock market conditions.

[0141] After the scenarios are generated, they are loaded into thescenario-tree and wScenario objects and, for each wScenario, theNativeOptimizer function is executed. In this case, the NativeOptimizerfunction can call DeterministicOptimizer, with iFlexStage equal to one.

[0142] The DeterministicOptimizer optimizes cash management, given adeterministic situation. It may initially determine available cash foreach stage and, as is possible, allocate such cash to the individualstages' cash requirements. If extra cash is available in various stages,such cash is optimally invested with consideration of definitely-known(i.e., certain) subsequent-stage requirements, rates of return, andtransaction costs. If cash is short, then investments are optimallyliquidated in various stages with consideration of definitely-knownsubsequent-stage requirements, rates of return, and transaction costs.And finally, the investments themselves are juggled with considerationof definitely-known subsequent-stage rates of return and transactioncosts. Corporate policy may dictate certain constraints and, ifpossible, such constraints should be respected. (The variety ofapproaches here is innumerable, and this is but one approach.)

[0143] The DeterministicOptimizer function in this case could, andpossibly should, entertain that which is usually considered unthinkable:defaulting on bonds, missing payroll, etc. In a given execution of thisfunction, the allocations for stages iFlexStage and beyond couldinitially result in certain catastrophes, for example: defaulting onbond obligations and missing payroll starting in stage iFlexStage+3. Theoptimization process might improve the matter by changing theallocations of stage iFlexStage and beyond. This might result, forexample, in meeting payroll in stage iFlexStage+3, and suffering a moreserious default in stage iFlexStage+4. (Clearly, making the best of thesituation, i.e., optimization, entails ethical judgments, survivalconsiderations, and trade-offs.)

[0144] The ValueAllocation function might return the present-value ofthe gains and losses occurring in each stage. Alternatively, it mightreturn the sum of VNM utilities resulting from the gains and lossesoccurring in each stage.

[0145] Processing proceeds as previously described until there is oneremaining zCluster, with its xAllocOpt.a1 allocation that indicates thecash allocations that should be made in the first stage.

Example 3 Optimizing a Financial Portfolio with Uncertain Future Returns

[0146] An investor owns various financial instruments (FIs), cash,stocks, bonds, derivatives (options), commercial paper, etc. Theinvestor wants to maximize the VNM-utility portfolio-value as of a yearfrom now.

[0147] Scenarios are generated using state-of-the-art techniques. Foreach FI that is or may be owned, twelve monthly prices and returns areincluded in each scenario.

[0148] After the scenarios are generated, they are loaded into thescenario-tree and wScenario objects, and the NativeOptimizer function isexecuted. In this case, the NativeOptimizer function can callDeterministicOptimizer, with iFlexStage set equal to one.

[0149] The DeterministicOptimizer optimizes the purchases and sales ofFIs, assuming the scenario occurs with certainty. This optimization mayconsider tax effects, transaction costs, discrete-block-size transactingrequirements, etc. When first-stage allocations are optimized (i.e.,iFlexStage=1) and if multiple first-stage allocations yield the samereturns, then a random process is used to select a first-stageallocation from among the optimal first-stage allocations.

[0150] The ValueAllocation function notes the value of the portfolio atthe end of the year, and converts the portfolio's monetary value into aVNM utility value. The VNM function can be specified by the investorusing a series of connected points that map portfolio-monetary value toutility.

[0151] Processing proceeds as previously described until there is oneremaining zCluster, with its xAllocOpt.a1 allocation that indicateswhich FIs the investor should presently own. Differences with actualpresent ownership are resolved by buying and selling FIs.

Example 4 Portfolio Replication with Uncertain Coupling

[0152] Some investment institutions need to replicate a portfolio, butcannot obtain the portfolio's individual financial instruments (FIs).Instead, other FIs are purchased to compose an imitation portfolio (IP)that is expected to perform like the genuine portfolio (GP).

[0153] Such mimicry can be optimized with the present invention in anmanner analogous to the portfolio example immediately above. Here, onlyfirst-stage allocations (a₁) that are expected to optimally endure asingle realization of random events (w₁) are required. Scenarios aregenerated using state-of-the-art techniques. Each scenario comprisessingle-period performance samples for each of the GP's FIs, and for eachof the FIs that can be used in the IP.

[0154] After the scenarios are created and loaded into the scenario-treeand wScenario objects, the NativeOptimizer function allocates cash tothe FIs that can be used in the IP, such that the return of the IPequals the return of the GP contained in the wScenario object. It islikely that multiple allocations can yield the same return, and so arandom process selects one such allocation.

[0155] In this example, the DeterministicOptimizer does nothing otherthan call the ValueAllocation function. ValueAllocation initiallydetermines the difference between the performance of the GP and the IP.A special VNM utility function, like those shown in FIGS. 13A and 13B,is used to convert the performance difference into a utility or a voavalue. In other words, the domain of these special VNM utilitiesfunctions is the difference (positive or negative) between the return ofthe IP and the return of the GP. (The utility function in 13A dictatesseeking a strict parallel performance between the GP and the IP; whilethe function in 13B suggests wanting a performance roughly equivalent tothe GP, though with a willingness to seek superior returns with theconcomitant risk that inferior returns will result.)

[0156] Processing proceeds as previously described until there is oneremaining zCluster, with its xAllocOpt.a1 allocation that specifies theFIs' quantities that should be owned to mimic the GP.

Example 5 Allocating Organizational Resources in an UncertainEnvironment

[0157] One of the more advanced methods for allocating resources ispresented in the PRPA. Because that method sometimes usesSimple-scenario analysis (as described earlier herein) for allocatingand pricing resources in an uncertain environment, those allocationsmight be sub-optimal. The present invention, however, can be coupledwith the PRPA to make superior allocations.

[0158] In this example, uncertainty is presumed present in resourceprices, product prices, potential demands, production coefficients,allocation-to-effectiveness-function specifications, and resourcequantities. This example has three stages or time periods. At least someof the groups/Apertures cross stages; hence their allocations affectmultiple periods.

[0159] The first step is to generate scenarios by randomly sampling foruncertain values. The generated scenarios are loaded into thescenario-tree and wScenario objects. NativeOptimizer function optimizesallocations, as described in the PRPA.

[0160] The ValueAllocation function determines the present-value of thechanges in WI_Cash (or Internal Producer's Surplus) during each timeperiod (stage).

[0161] The DeterministicOptimizer function performs optimizationsholding first-stage, or first-and second-stage allocations fixed. Eachexecution entails (given the previous allocations and the fixedscenarios) determining available WI_Cash, subtracting out earlier-stageconsumed resources, holding prior-stage group and non-group allocationsfixed, and then re-optimizing.

[0162] Processing proceeds as previously described until only onezCluster remains. Its xAllocOpt.a1 allocations are the a₁ allocations tobe initially implemented.

CONCLUSION

[0163] As the reader who is familiar with the domain of the presentinvention can see, this invention thus leads to optimized, ornear-optimized, resource allocations when uncertainty is present.

[0164] With such optimizations, both organizations and individuals cantherefore better reach their goals.

[0165] While the above description contains many particulars, theseshould not be construed as limitations on the scope of the presentinvention; but rather, as an exemplification of one preferred embodimentthereof. As the reader who is skilled in the invention's domain willappreciate, the invention's description here is oriented towardsfacilitating ease of comprehension. Such a reader will also appreciatethat the invention's computational performance can easily be improved byapplying both prior-art techniques and readily apparent improvements.

[0166] Many variations and many add-ons to the preferred embodiment arepossible. Their use frequently entails a trade-off betweenrequired-computer time and final-allocation quality, and theireffectiveness can be situationally contingent. Examples of variationsand add-ons include, without limitation:

[0167] 1. The Improver function does not necessarily need to usexAllocOpt for xAlloc0. Instead, two different xAllocs fromxAllocBestCntn could be randomly selected and copied to xAlloc0 andxAlloc1, preferably with xAlloc0.voa being superior to xAlloc1.voa. Therandom selection process should avoid repeated selection of the samepair in the same zCluster instance. Once clusters are merged, continuingto avoid repeating a pair might be desirable, since this would tend tofocus searching in the space between the previous-smaller-mergedclusters.

[0168] 2. The Improver function can skip any or all of the three searchfunctions (SPS, ICS, OCS). Omission results in obtaining a finalallocation faster, though it is likely be inferior to what could haveotherwise been obtained. (OCS is likely the least computationallyefficient of the three functions.)

[0169] 3. A further variation on variation #2 is to selectively use theImprover function. If, a priori, a single local optimum can be assumedfor the z function, then performance could be improved as follows. AfterStep 105 clusters, here termed Modal-clusters, that may contain theoptimal allocations are identified: clusters that have many scenariosand/or clusters that have scenarios with particularly high voa valuesare good Modal-clusters choices; clusters that would contain first-stageallocations as determined by Simple-scenario analysis and/orConvergent-scenario analysis are also good choices. After one or moreModal-clusters are identified, processing proceeds as previouslydescribed, except that 1) in Step 109, the Improver function is appliedonly to the Modal-clusters, and 2) in Step 113, when clusters aremerged, if an old non-Modal zCluster object yields a superior xAlloc forthe new zCluster object, then the old zCluster object's Improverfunction is immediately called, and the merging postponed until afterthe function is complete. (The result of merging a Modal withnon-Modal-cluster(s) is a Modal-cluster.)

[0170] An extreme use of Modal-clusters entails, in Step 103, using anallocation resulting from Simple-scenario analysis as a seed to build aModal-cluster having more than one wScenario objects. Afterwards, eachwScenario object not included in the Modal-cluster is loaded into itsown zCluster object (singleton). Then in each iteration of Step 113,only the singleton clusters relatively near the Modal-cluster are mergedinto the Modal-cluster, while the singletons relatively far from theModal-cluster are not merged until a subsequent iteration of Step 113.

[0171] 4. Standard line-search, non-derivative, and/or derivative basedtechniques could be incorporated in ZCluster::Improver for improvingfirst-stage allocations (stored as xAlloc objects in xAllocBestCntn).Such techniques might require some adaptation, including, for instance,incorporation of response surface methods (RSM techniques). (See A. R.Conn, K. Scheinberg, and Ph. L. Toint “Recent Progress in UnconstrainedNonlinear Optimization Without Derivatives” Mathematical Programming 79(1997), p. 397-414; and M. S. Bazaraa, H. D. Sherali, C. M. Shetty,Nonlinear Programming Theory and Algorithms 2nd ed., John Wiley & Sons.Inc., New York, 1993, [See particularly Chapter 8: “UnconstrainedOptimization” p. 265-355]. Both references also cite relevant previouspublications.) Incorporation of such standard line-search,non-derivative, and/or derivative based techniques in ZCluster::Improverwill be termed here as StandardSearch.

[0172] An example of StandardSearch is the use of the sequential simplexsearch technique developed by Nelder and Mead: some or all of the xAllocobjects stored in xAllocBestCntn could be used to define the simplex,which is in turn used to generate additional xAlloc objects (in a manneranalogous with the GenxAlloch function), which in turn are evaluatedusing XAllocEvaluator, which in turn redefine the simplex, etc.—allpotentially leading to a superior xAlloc.

[0173] 5. Well known genetic algorithms could be incorporated into theZCluster::Improver function to combine existing xAlloc objects inxAllocBestCntn to form additional xAlloc objects, which are evaluatedusing XAllocEvaluator. Naturally, the better resulting xAlloc objectsare added to xAllocBestCntn. Incorporation of genetic algorithms inZCluster::Improver will be termed here as GeneticSearch.

[0174] A simple means to implement GeneticSearch is to include in theImprover function calls to a special version of GenxAlloch. This specialversion would be identical to the regular version, except that adifferent value for h would be randomly generated for each iteration ofthe first loop.

[0175] 6. The equality-comparison operator of the XAlloc class couldinitially start with a loose tolerance, and as processing proceeds,become tighter. This might reduce potentially wasteful considerations ofroughly-equal allocations, when there are numerous xAllocs in numerouszClusters.

[0176] 7. If there are many scenarios in a cluster, theZCluster::XAllocEvaluator function could use statistical inference toconsider early termination. If statistical inference suggests that theresulting voa would not be very good, then xAlloc.voa should be set tothe estimated not-very-good value, the function exited, and processingotherwise continued. (The drawn-sample-scenario sequence should beconsistent.)

[0177] 8. If there are many wScenario objects, then initial clusteringcould be nested: clusters are initially formed based upon a₁allocations, then within each such cluster, another secondary clusteringis done based upon a₂ allocations, and so forth. The final (smallest)clusters would then be loaded into the zCluster objects.

[0178] 9. The maximum number of xAlloc objects held inZCluster::xAllocBestCntn could be variable, and thus the thoroughness ofthe optimization adjusted. The Improver function, and the functions itcalls, are continuously generating reasonable xAllocs that could besaved in xAllocBestCntn. Alternatively, after each iteration of theImprover function, xAlloc0 and/or xAlloc1 could be removed fromxAllocBestCntn if they do not equal xAllocOpt. Further, periodically thexAlloc objects in ZCluster::xAllocBestCntn could be evaluated forequivalence, and rough duplicates discarded.

[0179] 10. Scenario specifications, i.e., wScenario.wwMatrix, could beused as proxies for clustering based upon first-stage allocations. Whenscenario generation is performed by using formal sampling techniques,i.e., area sampling, cluster sampling, stratified sampling, systematicsampling, etc., clusters frequently automatically suggest themselves.Such naturally occurring clusters can be used as bases for initiallyloading the zCluster objects.

[0180] 11. Within each zCluster instance, any means can be used tocreate first-stage allocations (xAlloc objects), which then could beevaluated by the XAllocEvaluator function. Techniques for creatingfirst-stage allocations include: generating a weighted average of thenativeXAllocs contained in wScenarioCntn, and generating a weightedaverage of the xAllocs contained in xAllocBestCntn. Any xAlloc createdoutside of a zCluster instance could also be used. Incorporation of suchmethods will be termed here as MiscSearch.

[0181] 12. When multiple processors are available, they might desirablybe used for parallel execution of multiple instances of theZCluster::NativeOptimizer and the ZCluster::Improver functions and forparallel generation of GBSs. The generation of GBSs could be done byhaving each processor handle a branch of the scenario tree.

[0182] 13. The GBSs can be regenerated at any time, which beneficiallycalibrates the GBSs to the current-optimization state. This requires: 1)weighting each cluster by the cumulative probability that the scenarioswithin the cluster will occur, 2) randomly assigning, based upon clusterprobability, the clusters' xAllocOpt (or the xAllocs stored in theclusters' xAllocBestCntn) to the wNode s' xAllocRndCntn objects, and 3)proceeding with GBS generation as previously described.

[0183] 14. Contingent-GBSs could result in better allocations, butrequire more effort to generate. Contingent-GBSs are particularlyappropriate when earlier stage allocations make a significant differencefor the later stages. For example, a household's resource allocation isbeing optimized; a decision to buy or not buy a first home significantlyaffects what can be done in subsequent stages. To generateContingent-GBSs, processing proceeds as previously described for eachcontingent possibility: those xAllocs in wNode.xAllocRndCntn that resultin the first variation are used to generate the first variation GBS;those that result in the second variation are used to generate thesecond variation GBS, and so forth. Returning to the example, supposeContingent-GBSs are being developed for a fifth stage node; thosexAllocs that result in purchasing-a-house in stages 1, 2, 3, or 4 areused to generate the “house bought” GBS; while those that result innot-purchasing-a-house are used to generate the “no house bought” GBS.(When optimizing stage 5 allocations, the “house bought” GBS is used ifa house is bought during stages 1, 2, 3, or 4; otherwise, the “no housebought” GBS is used.)

[0184] The difficulty with this approach is that the xAllocs inxAllocRndCntn might not lead to every contingent variation. The simplestway around this is to suspend generating the Contingent-GBS until anxAlloc that results in the variation appears, and then using it togenerate the GBS. (Such xAllocs could be accumulated, and each time oneappears, the most recently accumulated xAllocs used to generate newGBSs.)

[0185] 15. Better GBSs can be generated by merging several scenarios tocreate an optimal GBS. Merged-GBSs are particularly appropriate when abranch of the scenario-tree lacks a central scenario that can serve as agood GBS. Merged-GBSs, however, require more effort to generate.

[0186] Generating Merged-GBSs is analogous to finding optimal clusterallocations: rather than finding optimal allocations for a set ofscenarios, optimal scenarios are found for a set of allocations. Thefollowing pseudo-code shows the GenMergedGBS class, which isconceptually based upon the ZCluster class, with WWMatrix replacingXAlloc. This pseudo-code generates a Merged-GBS for an iStage-stage nodenamed iNode; execution begins at the MainBody function. classGenMergedGBS( )   {   wwMatrixBestCntn;   wwMatrixOpt;  WWMatrixEvaluator(wwMatrix, OKadd)     {     AAMatrix aaMatrix;    WWMatrix wwMatrixTemp;     wwMatrixTemp = wwMatrix;     wwMatrix.voa= 0;     for(each xAlloc in iNode.xAllocRndCntn)       {       copyxAlloc.a1 to aaMatrix.aa[][1];       DeterministicOptimizer(2, aaMatrix,wwMatrixTemp);       for(jNode = each iStage+1 node following iNode)        {         DeterministicOptimizer(iStage+1, aaMatrix,          jNode.pGBS->wwMatrix);         wwMatrix.voa = wwMatrix.voa +          aaMatrix.voa * jNode.nodeProbability;         }       }      //... Analogously follows code after first loop in        ZCluster::XAllocEvaluator. ...     }  ConsiderAppendBestWWMatrix(wwMatrixAdd, wwMatrixDel);   MainBody( )    {     for(jNode = each iStage+1 node following iNode)      WWMatrixEvaluator(jNode.pGBS->wwMatrix, TRUE);     Improver( );    iNode.pGBS = (pointer to, copy of) wwMatrixOpt;     }   Improver( );  SimpleParabolaSearch( );   InnerCompressSearch( );  OuterCompressSearch( );   GenwwMatrixh(h)     {     Analogouslyfollows ZCluster::GenxAlloch, except first loop is     applied to all      columns of wwMatrix.     }   wwMatrixHurdle;   wasImproved;  wwMatrix0;   wwMatrix0off;   wwMatrix1;   wwMatrixh;   wwMatrixBnd;  }

[0187] 16. When scenarios cannot legitimately be merged, as is requiredfor Merged-GBSs, Multiple-GBSs can be used. The central idea ofMultiple-GBSs is to use several GBSs to generate multiple allocations,which in turn are merged.

[0188] Generating Multiple-GBSs is analogous to finding optimal clusterallocations: rather than finding an optimal allocation for a set ofscenarios, an optimal blending of multiple allocations is determined andthe blending steps are noted/recorded. Later, the blending steps arerepeated for blending other allocations.

[0189] Two additional classes are required. The MAAMatrix class (metaAAMatrix) is the same as the AAMatrix class, except that it containsmultiple aa arrays that are always accessed in the same order. TheGenMultipleGBS class is analogous to the ZCluster class, with MAAMatrixreplacing XAlloc, and is included in each wNode object havingMultiple-GBSs.

[0190] The following pseudo-code shows the process of generatingMultiple-GBSs for an iStage-stage node iNode. (For ease ofcomprehension, each node immediately following iNode is assumed to havea single GBS, as opposed to multiple GBSs.): MAAMatrix mAAMatrix;AAMatrix aaMatrix; GenMultipleGBS gmGBS; gmGBS.nElemAAMatrixBestArray =0; gmGBS.iStage = iStage; gmGBS.iNode = iNode; gmGBS.nRecorder = 0;for(jNode = each iStage+1 node following iNode)   {   empty mAAMatrix ofaa arrays;   for(each xAlloc in iNode.xAllocRndCntn)     {     copyxAlloc.a1 to aaMatrix.aa[][1];     DeterministicOptimizer(2, aaMatrix,jNode.pGBS->wwMatrix);     Add aaMatrix.aa to mAAMatrix;     }  gmGBS.MAAMatrixEvaluator(mAAMatrix, TRUE);   } gmGBS.Improver( );

[0191] The GenMultipleGBS class is conceptually based upon the ZClusterclass, with MAAMatrix replacing XAlloc. class GenMultipleGBS: public...  {   iStage;   iNode;   struct     {     index_h0;     index_h1;     h;    index_hResult;     } recorder[];   nRecorder;  mAAMatrixBestArray[]; //analogous with xAllocBestCntn.  nElemAAMatrixBestArray;   mAAMatrixOpt;   iMax;  MAAMatrixEvaluator(mAAMatrix, OKadd)     {     mAAMatrix.voa = 0;    for(jNode = each iStage+1 node following iNode)       {      for(aaMatrix = each aa array contained in mAAMatrix)         {        DeterministicOptimizer(iStage+1, aaMatrix,          jNode.pGBS->wwMatrix);         mAAMatrix.voa = mAAMatrix.voa +          aaMatrix.voa * jNode.nodeProbability;         }       }      //... Analogously follows code after first loop in        ZCluster::XAllocEvaluator. ...     }  ConsiderAppendBestMAAMatrix(mAAMatrixAdd, mAAMatrixDel)     {    if(nElemAAMatrixBestArray == 0 ∥       mAAMatrixBestArray[iMax].voa< mAAMatrixAdd.voa)         iMax = nElemAAMatrixBestArray;    mAAMatrixBestArray[nElemAAMatrixBestArray++] =       mAAMatrixAdd;    //positions need to be kept constant and elements not     //removed,so that re-play works correctly.     }   Improver( )     {

[0192] Follows ZCluster::Improver, except that when and ifConsiderAppendBestMAAMatrix is called because an iteration yields animprovement over the beginning mAAMatrixHurdle, the following is alsodone after the call to ConsiderAppendBestMAAMatrix:       {      recorder[nRecorder].index_h0 = i, such that      mAAMatrixBestArray[i]         = mAAMatrix0;      recorder[nRecorder].index_h1 = i, such that      mAAMatrixBestArray[i]         = mAAMatrix1;      recorder[nRecorder].h = mAAMatrixHurdle.h;      recorder[nRecorder].index_hResult = i, such that        mAAMatrixBestArray[i] = mAAMatrixHurdle;       nRecorder++;      }   } SimpleParabolaSearch( ); InnerCompressSearch( );OuterCompressSearch( ); GenMAAMatrixh(h)   {   for(k=each aa matrix inmAAMatrix)     {

[0193] Analogously apply first loop of ZCluster::GenxAlloch to mergecolumns 1 through iStage of kth aa array of mAAMatrix0 and mAAMatrix1into columns 1 through iStage of kth aa array of mAAMatrixh.   }   //...Analogously follows code after first loop in   ZCluster::GenxAlloch. ...  } mAAMatrixHurdle; wasImproved; mAAMatrix0; mAAMatrix0off; mAAMatrix1;mAAMatrixh; mAAMatrixBnd; }

[0194] Using Multiple-GBSs for generating the iStage-stage allocationsfor iNode entails not directly calling the DeterministicOptimizerfunction in EvaluateXAllocAgainstWScenario, but doing the followinginstead: { aaMatrixArray[]; //i.e., array of AAMatrix objects. i = 0;for(jNode = each iStage+1 node following iNode)   {  DeterministicOptimizer(iFlexStage, aaMatrix,    jNode.pGBS->wwMatrix);   aaMatrixArray[i++] = aaMatrix;   } for(i=0;i<gmGBS.nRecorder; i++)   {   using:    •aaMatrixArray[gmGBS.recorder[i].index_h0].aa[][iStage],     aaMatrixArray[gmGBS.recorder[i].index_h1].aa[][iStage],    •gmGBS.recorder[i].h;

[0195] apply processing analogous to first loop of ZCluster::GenxAllochto create merged values for column:    aaMatrixArray[gmGBS.recorder[i].index_hResult].aa[][iStage].   }Copy column aaMatrixArray[gmGBS.recorder[iMax].index_hResult].aa[][iStage] to   column aaMatrix.aa[][iStage]. } (Note: When loopingthrough the jNode objects, the sequence of fetching jNode objects  needs to be consistent.)

[0196] 17. Besides allocating resources, this invention can also valueresources, which as previously described, can be used to allocateresources.

[0197] Define a function zz(q,c) that both uses this invention (with anunchanging scenario-tree and associated scenarios; [the GBSs, however,may change]) to determinate an optimal allocation and that returns acomputed z value for equation 2.0, given that the available on-handquantity of a particular resource changes by q, and given that availableon-hand cash changes by c. (Both q and c can apply to different stages.)Given a particular q, well known numerical techniques can be used tofind c such that:

zz(0,0)=zz(q,c)

[0198] By economic theory, the value of the |q| units of the particularresource is |c|: if q is negative, then c is the minimal value thatshould be received for selling −q resource units; if q is positive, then−c is the maximal value that should be paid for buying q resource units.For small q, |c/q| equals unit price for the particular resource andsuch a price can be used for pricing.

[0199] Another means to generate similar data is to generate supply anddemand curves. If, within the scenarios, a resource can be sold and/orpurchased, then resource supply and demand curves can be generated byvarying resource price, performing Steps 101 through 113 with the samewScenario objects, and noting the resulting resource quantity changes.(Conceptually, produced products and services can be handled as a bundleof resources. Depending on the DeterministicOptimizer andNativeOptimizer functions, the q discussed here could instead referenceproduced product and service quantities.)

[0200] Given a resource optimization method, how to value and priceresources and how to beneficially use such values and prices is wellknown by economists. The point of this variation is that this inventioncan be used, as a resource optimization method, in conjunction withprior-art techniques to determine and use resource prices and values.And once such prices and values are determined, they can be used forinternal pricing and for deciding whether to buy or sell on the openmarket.

[0201] 18. Step 103 is not necessarily required, and it is acceptable,instead, to place all scenarios created in Step 101 into a singleZCluster. This could be desirable when there are only a few scenarios(and hence clustering is not worth the effort) or when the clusters arehighly disparate.

What I claim is:
 1. A system for optimally allocating resourcescomprising: a computer having at least one processor, means for datainput and output, and memory means for storing data and executableprograms; said memory means comprising a first memory portion storing aplurality of scenarios; a second memory portion storing an executableprogram means for loading said first memory portion; a third memoryportion for storing a plurality of XAlloc objects; a fourth memoryportion storing an executable program means for allocating resourceswithin each said scenario stored in said first memory portion; a fifthmemory portion storing an executable program means for evaluating anallocation contained in an XAlloc object against one or more scenariosof said first memory portion; a sixth memory portion for storing anexecutable program means for calling executable program means of saidsecond, fourth, and fifth memory portions and for performing executableprogram means on said first and third memory portions to optimallyallocate said resources.
 2. The system for optimally allocatingresources according to claim 1, wherein said sixth memory portionfurther comprises an executable program means for clustering saidscenarios of said first memory portion; said first memory portionfurther comprises a means for storing said clusters; said sixth memoryportion further comprises an executable program means for utilizing saidclusters to optimally allocate said resources.
 3. The system foroptimally allocating resources according to claim 1, wherein said sixthmemory portion further comprises at least one of the followingexecutable program means: SimpleParabolaSearch, InnerCompressSearch,OuterCompressSearch, GeneticSearch for combining XAlloc objects to formnew XAlloc objects; said sixth memory portion causing only preferablesaid new XAlloc objects to be stored in said memory portion three. 4.The system for optimally allocating resources according to claim 1,wherein said sixth memory portion further comprises at least one of thefollowing executable program means: StandardSearch, MiscSearch forgenerating XAlloc objects; said sixth memory portion causing onlypreferable said generated XAlloc objects to be stored in said memoryportion three.
 5. The system for optimally allocating resourcesaccording to claim 1, wherein said sixth memory portion furthercomprises an executable program means for generating Guiding BeaconScenarios; said fifth memory portion further comprising means for usingsaid generated Guiding Beacon Scenarios.
 6. The system for optimallyallocating resources according to claim 5, wherein said executableprogram means for generating Guiding Beacon Scenarios further includesmeans for generating at least one of the following types of GuidingBeacon Scenarios: Contingent, Merged, and Multiple; said means for usingsaid generated Guiding Beacon Scenarios further includes means for usingthe Guiding Beacon Scenarios generated by said means for generatingGuiding Beacon Scenarios.
 7. The method for optimally allocatingresources according to claim 6, wherein, at least one of the following:A) said sixth memory portion further stores an executable program meansfor clustering said scenarios of said first memory portion; said firstmemory portion further stores said clusters; said sixth memory portionfurther stores an executable program means for utilizing said clustersto optimally allocate said resources; B) said sixth memory portionfurther stores at least one of the following executable program means:SimpleParabolaSearch, InnerCompressSearch, OuterCompressSearch,GeneticSearch for combining XAlloc objects to form new XAlloc objects;said sixth memory portion causing only preferable said new XAllocobjects to be stored in said memory portion three; C) said sixth memoryportion further stores at least one of the following executable programmeans: StandardSearch, MiscSearch for generating XAlloc objects; saidsixth memory portion causing only preferable said generated XAllocobjects to be stored in said memory portion three.
 8. The method foroptimally allocating resources according to claim 1, wherein said methodcomprises at least two of the following: A) said sixth memory portionfurther stores an executable program means for clustering said scenariosof said first memory portion; said first memory portion further storessaid clusters; said sixth memory portion further stores an executableprogram means for utilizing said clusters to optimally allocate saidresources; B) said sixth memory portion further stores at least one ofthe following executable program means: SimpleParabolaSearch,InnerCompressSearch, OuterCompressSearch, GeneticSearch for combiningXAlloc objects to form new XAlloc objects; said sixth memory portioncausing only preferable said new XAlloc objects to be stored in saidmemory portion three; C) said sixth memory portion further stores atleast one of the following executable program means: StandardSearch,MiscSearch for generating XAlloc objects; said sixth memory portioncausing only preferable said generated XAlloc objects to be stored insaid memory portion three. D) said sixth memory portion further storesan executable program means for generating Guiding Beacon Scenarios;said fifth memory portion further stores means for using said generatedGuiding Beacon Scenarios.
 9. A method for optimally allocatingresources, utilizing a computer having at least one processor, means fordata input and output, and memory means for storing data and executableprograms; said method comprising: storing a plurality of scenarios in afirst portion of said memory means; storing in a second portion of saidmemory means an executable program means for loading said first memoryportion; storing XAlloc objects in a third portion of said memory means;storing in a fourth portion of said memory means an executable programmeans for allocating resources within each said scenario stored in saidfirst memory portion; storing in a fifth portion of said memory means anexecutable program means for evaluating an allocation contained in anXAlloc object against one or more scenarios of said first memoryportion; storing in a sixth portion of said memory means an executableprogram means for calling executable program means of said second,fourth, and fifth memory portions and for performing executable programmeans on said first and third memory portions to optimally allocate saidresources.
 10. The method for optimally allocating resources accordingto claim 9, wherein said sixth memory portion further stores anexecutable program means for clustering said scenarios of said firstmemory portion; said first memory portion further stores said clusters;said sixth memory portion further stores an executable program means forutilizing said clusters to optimally allocate said resources.
 11. Themethod for optimally allocating resources according to claim 9, whereinsaid sixth memory portion further stores at least one of the followingexecutable program means: SimpleParabolaSearch, InnerCompressSearch,OuterCompressSearch, GeneticSearch for combining XAlloc objects to formnew XAlloc objects; said sixth memory portion causing only preferablesaid new XAlloc objects to be stored in said memory portion three. 12.The method for optimally allocating resources according to claim 9,wherein said sixth memory portion further stores at least one of thefollowing executable program means: StandardSearch, MiscSearch forgenerating XAlloc objects; said sixth memory portion causing onlypreferable said generated XAlloc objects to be stored in said memoryportion three.
 13. The method for optimally allocating resourcesaccording to claim 9, wherein said sixth memory portion further storesan executable program means for generating Guiding Beacon Scenarios;said fifth memory portion further stores means for using said generatedGuiding Beacon Scenarios.
 14. The method for optimally allocatingresources according to claim 13, wherein said executable program meansfor generating Guiding Beacon Scenarios further includes means forgenerating at least one of the following types of Guiding BeaconScenarios: Contingent, Merged, and Multiple; said means for using saidgenerated Guiding Beacon Scenarios further including means for using theGuiding Beacon Scenarios generated by said means for generating GuidingBeacon Scenarios.
 15. The method for optimally allocating resourcesaccording to claim 14, wherein, at least one of the following: A) saidsixth memory portion further stores an executable program means forclustering said scenarios of said first memory portion; said firstmemory portion further stores said clusters; said sixth memory portionfurther stores an executable program means for utilizing said clustersto optimally allocate said resources. B) said sixth memory portionfurther stores at least one of the following executable program means:SimpleParabolaSearch, InnerCompressSearch, OuterCompressSearch,GeneticSearch for combining XAlloc objects to form new XAlloc objects;said sixth memory portion causing only preferable said new XAllocobjects to be stored in said memory portion three. C) said sixth memoryportion further stores at least one of the following executable programmeans: StandardSearch, MiscSearch for generating XAlloc objects; saidsixth memory portion causing only preferable said generated XAllocobjects to be stored in said memory portion three.
 16. The method foroptimally allocating resources according to claim 9, wherein, at leasttwo of the following: A) said sixth memory portion further stores anexecutable program means for clustering said scenarios of said firstmemory portion; said first memory portion further stores said clusters;said sixth memory portion further stores an executable program means forutilizing said clusters to optimally allocate said resources. B) saidsixth memory portion further stores at least one of the followingexecutable program means: SimpleParabolaSearch, InnerCompressSearch,OuterCompressSearch, GeneticSearch for combining XAlloc objects to formnew XAlloc objects; said sixth memory portion causing only preferablesaid new XAlloc objects to be stored in said memory portion three. C)said sixth memory portion further stores at least one of the followingexecutable program means: StandardSearch, MiscSearch for generatingXAlloc objects; said sixth memory portion causing only preferable saidgenerated XAlloc objects to be stored in said memory portion three. D)said sixth memory portion further stores an executable program means forgenerating Guiding Beacon Scenarios; said fifth memory portion furtherstores means for using said generated Guiding Beacon Scenarios.